Future agile optical networks are, at the request of customers, expected to quickly and automatically provision lightpaths. Successful provisioning depends on two basic functions of network control: routing and signaling. The routing function automatically updates the optical network topology and related resource information so that a node can compute a light path for the request. The signaling function ensures that the nodes along a computed route exchange the information to set up or tear down a lightpath without user intervention.
Most current control network approaches are based on the extension of existing Internet Protocols (IP). The IP routing protocol OSPF (Open Shortest Path First) and IS-IS (Intermediate System to Intermediate System) are extended to exchange optical network routing information and construct the optical routing information database. These extended protocols rely on the instant and periodic exchange of the link state information (LSA {Link State Advertisement} of OSPF, or LSPDU {Link State Protocol Data Unit} of IS-IS) between the directly connected (physically or logically) pairs of nodes, called neighbors. The extension of these routing protocols introduces new optical network related information that should be exchanged using the existing LSA or LSPDU mechanisms. This new information is coded by a number of Type/Length/Value triplets (TLV). For OSPF, these TLVs are exchanged by Opaque LSAs that are designed to exchange application related information. In the IS-IS protocol, the new TLVs are appended to the LSPDUs. In both cases, the information conveyed by the TLVs is not understandable by the protocol. There is no further processing by the protocol, other than checking the integrity of the data exchange, storing it in an internal format, and notifying interested applications that the information was received.
In the context of optical networks, the optical link information, such as end point IDs, link type, bandwidth, encoding type, shared risk group IDs, etc., are exchanged by the routing protocols. This information will be used or updated by different applications. For example, the route computation component needs the topology information and the related optical link properties to find a route to set up a lightpath the meets the constraints of the data. The link management applications, which interact with the routing protocol to add or remove an optical link on the node, can also update the information on an existing optical link, e.g., available resources changes.
There are basically three types of interactions between the applications and the routing engines for Optical Link State (OLS) information processing. The first changes the OLS information, e.g. adds or removes an optical link. In the second interaction the routing engine notifies interested applications that a new OLS is received, an existing OLS is deleted, an existing OLS is updated, etc. In the third interaction other applications use the OLS information for route computation, topology discovery, etc. Changes to the OLS information will cause the OLS information to flood the routing space.
As described above, all of the OLS information is stored in the internal format in a routing engine without further processing. It is possible that applications can access the OLS in the routing engine, but this type of access is unacceptable for the following reasons. First, as the OLS is encoded in TLVs, each time an application searches the information it needs to translate the TLVs into some readable data structure; this wastes time and processing power. Second, access to a specific routing engine requires creating applications with protocol-specific code; this limits the flexibility of the network. Additionally, the topology changes in an optical network are much less than in an IP network, so it would be beneficial to reduce the repetition in processing the TLVs.